Method of Providing Content to a Wireless Computing Device

ABSTRACT

A customised Network Application suitable for a specific type of Wireless Computing Device is automatically generated and sent to that Device. The Application is able to download a preview of content on demand by an end-user from a Server that stores the content and to play the preview of the content. It can also display an option or function that enables the end-user to download and buy that content from the Server. Attributes for that type of Wireless Computing Device are defined as Metadata; attributes for various different kinds of mobile content are also defined as Metadata; the Server then determines what content is compatible with the Wireless Computing Device by comparing the Metadata of the content and the Wireless Computing Device. The kind of content that can be provided includes ringtones, wallpapers/pictures, screensavers, realtones/truetones, full music downloads, video, SMS &amp; MMS alerts, and mobile games.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to a method of providing content to a WirelessComputing Device. The kind of content that can be provided includesringtones, wallpapers/pictures, screensavers, realtones/truetones, fullmusic downloads, video, SMS & MMS alerts, and mobile games.

2. Definitions

The definitions used in this specification are as follows:

Mobile Telephone: A type of telephone which is connected to thetelephone network via wireless technology through the air rather thanthrough a physical wire or other physical connection or form of cable.

Mobile Phone, Phone, Mobile, Mobile Handset or Handset: A type of MobileTelephone.

Mobile Network: A network which provides wireless connectivity forMobile Telephones so that they can operate and provide functions such asmaking telephone calls or accessing network-resident data or services.

Mobile Network Operator (MNO): A company or organisation which operatesa Mobile Network and the subscribers or users who use Mobile Telephoneson that network.

Global Mobile Network or Mobile Phone Network: The sum of all MobileNetworks operated by Mobile Network Operators in the world.

Wireless Network: A network which provides wireless connectivity toclient computing devices. Such a network includes Wi-Fi WiMAX and theGlobal Mobile Network.

Server: A networked computing device which exists to provide networkedapplication services, features and functions such as information supply,database search and transactions to one or more client computing deviceswhich make connection to it and make requests for services from it.There are generally many clients to each server and each client isusually of a smaller size and of smaller computing capability than theserver.

Services: The networked computing services, features and functions whichare typically provided by a Server to one or more network connectedclient computing devices. Services include information supply, databasesearch and transactions. Such services are architecturally practical todeploy centrally in the network and typically impractical to deploy on aclient computer due to the client's size and power.

Client: A computing device connected to a network delivering thefeatures and functions of a network-centric application to the user orconsumer of the application. The Client typically connects to a Serverand requests Services.

Network Application: A type of application or service that isnetwork-centric, in that it is delivered by a combination of softwarerunning on a Client performing the function of the application'sinterface to the end user or consumer, supported and complemented byServices provided by software on a Server which are accessed by theClient over a network.

Wireless Computing Device: A type of Client which connects to thenetwork via a Wireless Network. Such devices include Mobile Telephones,Personal Digital Assistants (PDAs), Games Consoles (e.g. Sony PSP) orother wirelessly network connected client computing devices. The type ofthe Wireless Computing Device is further defined by it's Manufacturer,Make, Version, Operating System, Firmware Version.

Wireless Device or Wireless Client: A type of Wireless Computing Device.

Software Application The Client software application which is to bedelivered over-the-air to, or pre-installed on, the Wireless ComputingDevice.

Software Components Individual units of software which form thecomponents of the Software Application which is being customised for theWireless Computer Device and part of the Device Adaptive Architecture(DAA) software library.

Mobile Content: Digital files and data representing electronic productsused by, consumed, played, viewed or rendered on Mobile Phones. Examplesinclude ringtones/ring tunes, wallpapers/pictures,screensavers/animations, realtones/truetones, full music downloads,video, SMS & MMS alerts, mobile games, and many other current andemerging Mobile Phone consumable entertainment and information products.

Metadata: Individual items of data or collections of data, potentiallyhierarchically related, which describe the attributes or behaviour ofWireless Computing Devices, Wireless Networks, Software Components,Network Applications or Mobile Content.

3. Description of the Prior Art

At the time of writing there are more Mobile Telephones in the worldthan there are personal computers (PCs). The nature of a MobileTelephone is that it generally spends more time switched on and in it'sowner's presence than a PC. These Handsets are increasingly powerfulcomputers with rich functions and capable hardware which, given thatthey are connected to the world's vast Mobile Networks and through theseto the Internet, provide a very compelling platform to deliver asignificant number of Network Applications to their users.

The Global Mobile Network is one of the first examples of a networkwhere a vast number of Wireless Computing Devices with widely differentoperating systems and platforms are connected to the network and candeliver Network Applications. The PC dominated Internet network differssignificantly from the Global Mobile Network because there are a muchsmaller number of Client operating systems and platform variants. Eventhough the Clients on the Internet are extremely powerful computingdevices they are predominantly similar to each other given the dominanceof a small number of operating systems from companies such as Microsoftand Apple. The effect of this is that if one builds the Client componentof a Network Application for the PC Internet on just Microsoft Windows,or perhaps the next one or two most prevalent Client architectures, thenone can deploy a similarly behaving Network Application across a veryhigh percentage of existing devices and therefore have a technically andpotentially commercially viable product. Moreover in the PC Internetworld it is possible to target similar groups of users very effectivelyby choosing to build the Client part of a Network Application using aparticular operating system or platform. For example if one were tobuild a Network Application for Financial Directors of companies thevast majority of these could be supported by building Client softwarecompatible with Microsoft Windows.

The same is not true of the Global Mobile Network. There are very manymore Wireless Client operating systems and platform variants than existon the PC Internet. As a consequence of this and also because of theextremely fast rate of development of functional enhancements andfeature additions to Mobile Phones, the devices vary a lot more in theirbehaviour as do the operating systems and platforms used to access andcontrol this behaviour. In addition to this it is not feasible toidentify and target a group of users by their role who use the same orvery similar Wireless Devices.

Generally speaking, the more Wireless Clients a Network Application canoperate on, the greater the financial opportunity for the provider ofthe application as more customers can be reached. For this reason it isparticularly interesting to providers of such Network Applications to beable to deploy software on the most Clients possible.

Network Applications and services are commonplace in the networked PCworld, and represent very big business opportunities due to the size ofthe Internet and thus the potential number of users. There are a smallnumber of ways in which the software implementing the Client part of anapplication is currently architected. These are as follows:

1. ‘Custom Built Applications’

End user computer devices (e.g. PCs) which can act as Clients to aNetwork Application generally provide a platform on which softwareprograms can be run. These platforms are typically the computer'soperating system (e.g. Microsoft Windows, Linux, Mac OS, Unix, etc) or aplatform layer on top of the operating system which allows softwareprograms to be run (e.g. Java). Custom Built Applications are built fromsoftware which can be run on one of these platforms. The software in theapplication makes calls to the platform and the platform in turnperforms a service for the application (e.g. drawing a window or sendinginformation across the network).

These platforms typically have a very rich set of features which areavailable to the Custom Built Application, in fact they normally offerall the features and facilities of the computer. As such Custom BuiltApplications can provide very rich user interfaces, wide-rangingfunctionality and can normally do anything that the Client is capableof. Examples of such applications (though not so network focused) arethe well known Microsoft Office tools such as Word, Excel andPowerPoint.

Due to the dominance of PC platforms, such as Microsoft Windows, it ispossible to develop a Custom Built Application and have it runsuccessfully on many of the world's PCs. However, if the application isrequired to run on more than one platform a port of the application isrequired to that platform or if the platform is significantly differenta full rewrite of the application is required. Porting and rewritingapplications is a very significant and costly engineering exercise, theeffort required increases with each additional feature in theapplication.

In summary, Custom Built Applications provide the richest possiblefeature set and best interface for the end user experience but theseapplications are only viable on a relatively small number of platformsdue to the engineering effort required to port from one platform toanother.

The problem with this approach is that it cannot run on a new Clientplatform unless the Client part of the Network Application has beenfully ported to the new Client platform. This is fine in the PC worldwhere there is little requirement to port applications and in any casethere are few Client platforms and very few new Client platforms, butthe Global Mobile Network presents an problem of immense complexity bycomparison with its myriad existing operating systems and types ofWireless Device and a constant flow of new Client devices coming intothe market at an unprecedented rate.

2. ‘World Wide Web Applications’

The World Wide Web (WWW) was originally designed as a network-basedinter-document referencing and navigation system which allowed users tobrowse between links from one document to another potentially ondifferent machines, potentially on different sides of the world. Thistechnology was facilitated by a standard mark-up language in whichdocuments were written, called hyper-text mark-up language (HTML), andthe HTML browser. HTML browsers are software applications which run on auser's Client displaying HTML documents and allowing navigation betweendocuments using HTML hyper-text links.

The technology became very popular because HTML browsers were soonwritten for most client computers. This meant that all networkedcomputer users had access to the same ever extending world-wide libraryof information and documents. It also meant that people who wished topublish information need only mark-up the document once in HTML to haveit accessible by the vast majority of networked computers in the world.

As time went on, users demanded more and more from this WWW technologyand many more features were added. New features included the ability toadd small amounts of software embedded into the pages being displayed(applets and scripts) which in turn allowed more functional applicationsto be built taking advantage of more of the Client's capabilities. Otherfeatures included forms for data collection and submission across thenetwork of data collected to software Services resident on Servers.

The end result was that quite capable Network Applications could bedeployed on a WWW Server and the vast majority of the world's Clientcomputers using browsers were able to access and operate theapplication. This represented an opposite extreme to the Custom BuiltApplication in that although WWW Applications could not be used to buildan application as functionality rich on the Client, it would however runon the majority of the world's PC Client computers without having to beported to each different platform.

The compromise inherent in this type of WWW Application is that the HTMLbrowser is the platform through which the Client part of the NetworkApplication accesses the capabilities of the Client. However the HTMLbrowser has access to significantly less features and commonlysignificantly less powerful features of the Client operating system. Inconsequence the range of features which can be implemented in a WWWApplication are fewer and less rich than a Custom Built Application. Inaddition because HTML is a standard to be commonly interpreted by allHTML browsers, the features available to a WWW Application are thefeatures which are common to all Client platforms. This presents aproblem in the Wireless Mobile Network where the features of MobileClients are evolving so rapidly that not only are they not common but itis desirable to deploy Network Applications which use features that arenot common across different Wireless Devices including the newestfeatures.

There are methods by which WWW Applications can deploy richer featuresand more advanced Client specific application code, for example byembedding Microsoft ActiveX or Java code. This has the effect of makingthe application a combination of a WWW Application and a Custom BuiltApplication or a WWW Application and a Write Once, Run AnywhereApplication (depending on the nature of the embedded code) and have thecombined issues and limitations of two of these types of application.

3. ‘Write Once, Run Anywhere Applications’

Write Once, Run Anywhere Applications are meant to provide the bestfeatures from the worlds of Custom Built Applications and WWWApplications. As their name suggests, the application is defined onlyonce yet the same consistent and functionally rich application will runon many platforms without having to port the application. This isachieved in one of two ways:

i) Virtual Machines'

A Virtual Machine is an intermediary software platform which sits on aClient's own platform (e.g. operating system) and runs the Write Once,Run Anywhere Application. This is achieved because the applicationsoftware is able to be read line by line by the Virtual Machine and theinstructions are interpreted on-the-fly into corresponding native callsto the Client's platform.

The end result of this approach is that if a Virtual Machine is writtenfor every significant Client platform then one is able to develop asingle computer program compatible with the Virtual Machine which canproduce a user experience much functionally richer than a WWWApplication (as there is access to more of the Client's platformfeatures) without having to port the application to each Clientplatform. An example of this technology is Sun Microsystems Java.

The problem with this approach is that if the Client software has anyinternal complexity (e.g. is scientific in nature, makes use of softwarethreads, has near-real-time graphics or any other real-time properties)then a like performance of the application becomes much more difficultto ensure across multiple different types of Clients. This is the reasonthat a mobile Java Game never runs on all Java Clients but only a smallsubset which has been specifically tested by the originator of the gameto ensure that the user experience remains the same. This is whyprogrammers often say “Write Once, Debug Everywhere”. This problem cannever be obviated using the Virtual Machine technique.

ii) ‘Pseudo Code Compilers’

Pseudo Code Compilers achieve a similar outcome using a differentmethod. Similar to Virtual Machines, the software representing theapplication is written once and is represented in a high level formwhich can be interpreted by other software. However rather thandeploying a Virtual Machine platform on every target Client whichinterprets the application code on-the-fly, before the application codeis sent to the Client a compiler reads through the application andbuilds (compiles) a native application which will run directly on theClient's operating system platform.

This way a single representation of a rich featured application can bedeveloped and it can be run on any Client for which a compiler exists.An example of such a system is Sybase's PowerBuilder (which incidentallycan also implement a version of the Virtual Machine architecture usingit's ‘P-Code’ technology).

The problem with both these approaches are identical to that of CustomBuilt Applications, except that in these cases it is the compiler or theinterpreter which must be re-written for every target Client platform.Similarly, that presents no great problem in the PC world where thereare few operating systems but it presents an almost insurmountablehurdle in the Mobile Network world where you cannot deliver anapplication unless you can first deliver the compiler or theinterpreter. It's an inescapable catch-22.

In summary of these three methods, PC Network Applications can bedeveloped as:

-   -   Custom Built Applications if you want rich features and        functions but only want it to run on a small number of types of        Client platform, or    -   WWW Applications if you want to define them once, have them run        everywhere but are happy to live with a limited user experience,        or    -   Write Once, Run Anywhere Applications if you want to define them        once and have them run on many platforms.

In the world of Mobile Phones the environment is significantlydifferent. The major differences are as follows:

-   -   There are many more Mobile Devices in use connected to many        different Mobile Networks.    -   There are significantly more manufacturers of Mobile Phones each        with potentially multiple Client platforms resulting in many        more varieties of Client platforms on which applications need to        run.    -   The capabilities of Mobile Phones change very rapidly as more        and more features are added. The end result is that two        different Mobile Phones can have very different capabilities,        quite unlike PC Clients which tend to be very similar.

In order to maximise the financial potential of a Network Applicationdelivered using Mobile Phone technology the requirements are:

-   -   Enable the application to run on as many Mobile Devices as        possible;    -   Enable the application to be rapidly commissioned onto new        Phones as they are released;    -   Enable the application to take advantage of the best and most        appropriate features of each Mobile Device, as opposed to just        running the same application definition everywhere.

Most of the world's Mobile Phones do have a Wireless ApplicationProtocol (WAP) or eXtended HTML (xHTML) browser installed. Thesebrowsers and associated document based mark-up languages are directlycomparable to the architecture of the WWW Application. Using this MobilePhone technology it is possible to develop a Network Application whichwill run on neatly all the world's Handsets. The problem is that,similar to the restrictions of WWW Applications, WAP & xHTML can onlyutilise a very small subset of each Mobile Phone's capabilities. It isnot possible to develop the most functionally rich user experience usingthese technologies as they don't have access to the most advancedfeatures of the Phone.

A significant proportion of Mobile Phones now come with a Clientplatform onto which applications can be deployed. Most significantlythese include Java (or Java 2 Mobile Edition—J2ME), Symbian and Brew.Java is the most widely adopted of these technologies but, like Symbianand Brew, applications built with the technology still have seriousissues and limitations. There are nearly two billion instances ofthousands of different types of Phones on hundreds of different MobileNetworks. This presents the Java platform and Client applicationbuilding in general with the following problems:

-   -   Different Phones have different versions of Java.    -   Different Phones have different Java bugs.    -   Different Phones have different parts of the Java platform        implemented.    -   Every Phone has many different releases of operating system and        firmware which means there are behavioural differences on Phones        of the same type of a different age.    -   The same Phone can exist with several identities (for example,        MNO branded version of Phones).    -   Every Phone has different physical characteristics like screen        size, number of pixels, colour depth, keyboard controls,        soft-key characteristics etc.    -   Every Phone has different computing capabilities like processor        speed and memory size.    -   Every Phone has a different set of media files and formats that        can be shown via Java (e.g. audio, pictures, video, animations,        etc). Sometimes these are different from the formats that the        Phone lets the user use in native Phone applications, such as        setting a screen wallpaper.    -   Every Phone has different software limitations (two Phones may        have the same amount of memory but they allow an application to        use different amounts).    -   Every Phone has a different set of media files and formats that        the Phone's operating system can handle and these are        potentially different from those that can be handled by Java or        the platform which runs the application on the Phone.    -   Phones handle their network connection in many different ways,        the technologies are different, the settings are different, the        user prompts are different, the way settings are sent and        handled by the Phone are different, the way connections are        managed can be different.    -   Different Phones have different networking capabilities and        handling (e.g. CSD, GPRS, 2G, 2.5G, 3G, WAP, SMS, Bluetooth,        Infrared, Wi-Fi, WiMAX etc)

This means that although software language consolidation platforms likeJava can be available on a very large proportion of the world's Phonesand provide a useful programming language for deploying applicationsthat can use the advanced features of a Phone to produce a rich userexperience, in practice every different Phone requires a custom builtapplication to navigate and alleviate their many differences.

There is no previously existing technology, platform or method that hasever had to meet the challenge of rapidly and efficiently delivering themost functionally rich applications to the most Wireless ComputingDevices optimised for each device.

Because all Phones differ in these ways to some degree the only way todeliver an application using the most advanced features of each Phone tothe most Phones is to deliver a custom built application for eachdifferent Handset. If one used a traditional approach to this problem,whichever approach was used, the net result would be an inordinate andunmanageable amount of porting. This would end up with a new “stream” ofcode used to build the application for each new Phone. This is veryexpensive and maintenance becomes more and more difficult the morestreams of source code you add. The net result is that it isprohibitively expensive to build an application where the source codefor the application has been tuned for each device. It's clear that anew approach is needed.

A feature of current Mobile Content distribution is that users aregenerally just given a list of that Mobile Content on their Handsets(e.g. a list of downloadable items, such as the names of differentringtones, wallpapers etc.); from this menu list, a user can select theitem he wishes to download, causing a message to be sent to the Serverthat hosts the Mobile Content. The Server then returns the requesteditem. This limited model is dictated in large part by the fact that theContent distribution model typically relies on WAP sites and the kind ofinteractions possible between a WAP browser on a Handset and the Serverhosting the Mobile Content. The present invention enables more complexinteractions relating to Mobile Content to occur.

SUMMARY OF THE INVENTION

A customised Network Application suitable for a specific type ofWireless Computing Device is automatically generated and sent to thatDevice. The Application is able to download a preview of content ondemand by an end-user from a Server that stores the content and to playthe preview of the content. It can also display an option or functionthat enables the end-user to download and buy that content from theServer. Attributes for that type of Wireless Computing Device aredefined as meta-data; attributes for various different kinds of MobileContent are also defined as Metadata; the Server then determines whatMobile Content is compatible with the Wireless Computing Device bycomparing the Metadata of the Mobile Content and the Wireless ComputingDevice.

The kind of Mobile Content that can be provided includes ringtones,wallpapers/pictures, screensavers, realtones/truetones, full musicdownloads, video, SMS & MMS alerts, and mobile games.

The present invention is predicated on being able to deploy a customisedNetwork Application, as opposed to, for example, a simple WAP browserwith limited functionality. Building that customised Network Applicationcan be achieved in one implementation by using a Device AdaptiveArchitecture (DAA), which will be described in detail.

Further details and aspects are defined in the appended Claims.

DETAILED DESCRIPTION

This Detailed Description is divided into 2 sections. Section 1 dealswith the Device Adaptive Architecture (DAA). Section 2 deals with theMobile Content Portal; it is the latter that is the specific subjectmatter of this invention. However, an optimal implementation relies onthe Device Adaptive Architecture.

Section 1 Device Adaptive Architecture

The principles of the DAA solution to the challenge of building aplatform for deploying the most functionally rich Network Applicationsto the largest number of Wireless Client Devices in the most efficientmanner are:

-   -   Every Handset needs a unique application to maximise the user        experience.    -   The differences between Phones capabilities and features are        described and hence represented predominantly in Metadata, not        in software. Examples of the Metadata collected for each Handset        during the Handset commissioning process can be found in        Appendix 1—Handset Metadata. Examples are also provided of how        this Metadata varies from device to device.    -   The reference point for the differences between each phone is        the Metadata used to represent that Phone (see Appendix        1—Handset Metadata). Even though this Metadata is eventually        utilised to choose individual Software Components which are used        to form the Software Application, the reference point is the        Metadata for that Phone as the Software Application can be        deleted and rebuilt.    -   The Software Application for a particular Handset is built        automatically by the Device Adaptive Architecture software using        on the one hand the Metadata used to describe the unique        capabilities and idiosyncrasies of the device (see Appendix        1—Handset Metadata), and on the other hand the Metadata used to        describe a library of Software Components that can be compiled        dynamically into an application suitable for that device (see        Appendix 2—Handset Software Component Library). The Software        Component library is full of small software components, as        opposed to larger less granular units. Each Software Component        could be selected to form part of the Software Application based        on the Metadata describing the function and method of        configuring each Software Component and the Metadata describing        the attributes of the device. See Appendix 3—Examples of Mapping        Handset Metadata to Software Components.    -   A rapid method by which the Metadata describing the unique        nature of each Handset, used to build the customised Software        Application for that Handset, can be added to the platform. If a        Handset is commissioned using a combination of existing Software        Components without any modification required then that is        achieved by configuring the Handset Metadata alone. If new or        existing software code needs engineering then new or existing        Software Components with associated descriptive Metadata will be        added or altered in the library.    -   A rapid method by which new or existing Software Components can        be added to or modified in the library when a Handset is        discovered which implements functionality using methods and        technologies which are not yet available in the library. A new        or modified Software Component can be quickly added by placing        the new file containing the software in the file system of the        library. This is supplemented by Metadata describing the        conditions in which the Software Component is used or the way in        which it is configured for use inside the build of a Software        Application.    -   An additional Metadata and mark-up syntax on top of this which        allows many different Network Applications to be deployed to        this newly supported Handset with the minimum amount of Handset        specific software developed. See Appendix 4—End User Application        Metadata and Mark-up.    -   The ability to update the Software Application dynamically on        the Phone after install.    -   The ability for the Client to report its status and key        parameters to the Server to allow for further user specific        tuning. For example the Software Application can run tests to        determine the Client's current available persistent and dynamic        heap memory space available which could influence the size of        any deck updates made to the Client's Software Application so as        to avoid overrunning maximum memory size permitted.    -   The archiving of every unique instance of the Software        Application.

The first thing to do to support a new Handset is to acquire the Handsetfor the purposes of commissioning. A simple generic test application isdownloaded to the Handset which identifies the core packages availableon the Handset platform. Using this information a test applicationaligned with the Handset's capabilities is dynamically selected. Thistest application is downloaded to the Handset to electronicallyinvestigate the capabilities and features of the Handset and alsoinclude tests of historic bugs which were found on other Phones. Thistest application accumulates the results of it's tests as a set ofMetadata representing many of the Phone's attributes and idiosyncrasies.This Metadata is then written into a data store and related to that typeand build of Phone (see Appendix 1—Handset Metadata).

Manual inspection and testing of the various Handset capabilities andidiosyncrasies is then carried out, the results of which are similarlystored in the data store against the Handset supplementing the initialdata set from the test application. Once all information has beenretrieved and all initial tests completed there is enough data topotentially use the platform to build a custom built SoftwareApplication for this new Handset.

Various other Handset specific information which is not used in thebuild of the Software Application for that Handset is also collected.This information is collected for use in systems supporting theoperation of Software Applications built for this Handset. For examplethe location of where network settings are stored on a particularHandset is recorded so that the user can be helped with Handset specificguidance at the appropriate point in the application. See ‘UserAssistance Properties’ in Appendix 1-Handset Metadata.

At the heart of the Device Adaptive Architecture (DAA) is the enginewhich dynamically builds a Software Application for each Handset, orpotentially Handset/Mobile Network combination. The DAA reads theMetadata representing the capabilities of a Handset thencross-references these capabilities with the Metadata describing thecapabilities and configuration options of the Software Components in thelibrary, see Appendix 3—Examples of Mapping Handset Metadata to SoftwareComponents. The DAA then combines the selected Software Componentsconfigured in the manner required into a Client Software Applicationcustom generated for that Handset and potentially Mobile Networkcombination.

This then represents a Software Application customised for thisparticular Handset which is actually a platform for executingapplications rather than a functional end user application itself. Inother words this exercise has dynamically and automatically built anapplication execution platform which is downloaded to the Handset andrequires an application, itself defined in Metadata, to actuallyimplement an end user application or service, see Appendix 4—End UserApplication Metadata and Mark-up. This Metadata describing theapplication is then added to the generated application executionplatform software and the end result is a software program which wheninstalled and run on the Handset implements the end user application.

Each time an Software Application is built for a particular Handset aninstance of this application is stored in the archive of builds. Thearchive contains 100s of different builds for each version of theSoftware Application as an historic record. Historical builds can alsobe reproduced at anytime by simply re-running the DAA's dynamic buildprocess using the Handset Metadata and the Software Component versionsand associated Metadata valid at that time.

This candidate Software Application build then goes through a humanbased system testing process to confirm that the application operatescorrectly on the new Handset. This sometimes results in full success,sometimes it results in a requirement to change the Handset Metadata,rebuild the application and retest and sometimes it results in some ofthe Software Components having to go into engineering for maintenance ornew Software Components to be built followed by rebuild of theapplication and subsequent retest. Ultimately a fully functioningSoftware Application is available for this Handset and when it haspassed the system test it is then promoted to the production system forlive use by end users.

The particular Mobile Network to which a Handset is connected can alsoinfluence the build of the application for that Handset. UnderstandingMNOs and their network configurations in detail is just as important tothe DAA as understanding the Handsets in detail, so that the correctbuild for an MNO can be delivered to the Handset if required. SeeAppendix 5—Network Operator Metadata for details.

When a user's device connects to the system to request the download of aSoftware Application over the network the Handset informs the system ofits User Agent Profile (UAProf). This describes the phone manufacturer,model and firmware. Sometimes the Software Application required by aHandset has to also be customised to the Mobile Network on which theuser is connected, sometimes even the payment contract they have withthe MNO (e.g. pre-pay or monthly contract). In this situation the MobileNetwork on which the Handset is connected is detected either by the MNOinformation found inside the requesting SMS, the route the SMS camethrough, the IP address of the MNO gateway through which the request isbeing made, via an MNO core network lookup (e.g. SS7/HLR if available),Phone number (MSISDN) lookup against MNO number range assignations andported number databases or by simply asking the user in the screensprior to download. The system uses the most reliable method madeavailable to it. The UAProf, potentially combined with details of theMNO and payment contract type, is the key to choosing the correct,previously generated application to be presented for download by theconnected Handset.

For the purposes of implementing end user billing or end user tracking,and potentially end user support, it is important to be able to uniquelyand separately identify every instance of a Software Applicationdownloaded by every Handset and the Mobile Telephone Number (MSISDN) ofthe Handset which that Software Application instance is installed on. Inorder to do this the DAA builds a unique reference number into theSoftware Application before or at the time of the download. Thisreference number is related in the Server data store to the user'sMSISDN which was acquired from the end user whilst they were requestingthe Software Application (e.g. from the SMS requesting the applicationor the MSISDN collected on the web form, etc). When the nowClient-resident Software Application subsequently makes a request forServices from the Server it automatically provides the unique SoftwareApplication instance ID. Should the MSISDN be required then the uniqueinstance ID can be used to look it up.

We have discussed how a Software Application automatically generated bythe DAA is custom built for each Mobile Telephone as identified bymanufacturer, device type and potentially firmware (embedded devicesoftware) version or Mobile Network to which the device is connected.When a device connects to the Server for the purpose of acquiring aSoftware Application the Server determines these variable attributes andselects the application appropriate for this Phone.

However there are significant commercial opportunities associated withhaving such Software Applications pre-installed on users' Phones suchthat they are present on the Mobile Device at the time users acquiretheir Handset.

There are typically two places where applications can be pre-installedon a Mobile Phone before the user acquires the Phone. The first is inthe manufacturing of the device by its vendor (or manufacturingsubcontractors). The second is at a device configuring/provisioningfacility in the supply chain to the end user (either a Mobile Phonedistributor or retailer).

In either of these situations the Mobile Phone is, or can be, at somepoint connected to equipment which provisions (controls the setup of)the Mobile Telephone. At this point our systems interface with thatprovisioning equipment such that it has access to versions of anySoftware Application which is to be pre-installed on the Handset.

In this way the appropriate Software Application will be made availableto the provisioning equipment to enable it to be placed on the MobileDevice. However since the application installed on the Handset might notbe able to access the MSISDN of the Mobile Phone, this is different toproviding an unique Software Application to every single device with aninbuilt unique instance ID reference inside the application which can betransmitted back to the server and there related to the user's MSISDNfor the purpose of billing (for example). Instead the application willbe common to all Mobile Phones which share the same vendor, model,firmware and potentially Mobile Network to which they are/will beconnected. Therefore this relationship to MSISDN needs to be maderetrospectively after the Software Application has been installed on theMobile Phone. This is done as follows:

-   -   1. The Software Application specific to the Mobile Phone/Network        combination is pre-installed on the Phone by interfacing with        the Mobile Telephone provisioning equipment and supplying it        with all the Software Application builds it needs and the        vendor/model/firmware/network information relating to each        Software Application version so that the correct one can be        chosen and installed;    -   2. The Mobile Phone is acquired by an end user;    -   3. The end user turns on the device, discovers the Software        Application and starts it;    -   4. When the Software Application connects to the Server it        describes itself as a pre-installed application (by making a        request with no associated application instance ID) and presents        the information relating to the attributes which were used in        the selection of this Software Application for this device (e.g.        phone vendor/model/firmware/network).    -   5. This information is enough to allow the Server to create an        instance record, with an associated unique ID, for this Software        Application and to assign this unique reference to this instance        of the Software Application. The unique ID is passed back to the        Software Application over the network and the application stores        this ID locally and presents it on all subsequent Server Service        requests (just as if it had been built into the Software        Application in the first place).    -   6. The Server is also able to determine, from the data initially        presented above, what the appropriate content types are for this        device so that content applications can deliver the correct type        and format of Mobile Content for the Handset.    -   7. The end user can thus use all parts of the Software        Application that are available without the system requiring the        phone's MSISDN.    -   8. If the user accesses part of a Software Application that        requires the MSISDN and the MSISDN is accessible to the Software        Application, then it is read and sent to the Server as part of        the request for the Service. It will then be written into the        database of the Server where it will be related to the        application reference ID. It will therefore not be required to        be sent from the Software Application again.    -   9. If the user accesses part of a Software Application that        requires the MSISDN and the MSISDN is not accessible to the        Software Application then depending on the capabilities of the        Software Application in combination with the Handset the        following will happen:        -   a) If the Handset provides the Software Application with the            ability to send an SMS, then an SMS will be sent to the            Server containing the unique instance ID of the Software            Application. This SMS is received by the Server and enables            the Server to associate the unique application instance ID            with the MSISDN it determined from the incoming SMS.        -   b) If the method the Software Application uses to connect to            the Mobile Network allows the forwarding of the MSISDN to            the Server (e.g. via special modems which place the            connecting MSISDN on the request headers, or via MNO            communications gateways which can provide the MSISDN in the            header of the communication) then this can be used by the            Server to detect the MSISDN and have the association made            between the MSISDN and the application instance ID in the            Server's database.        -   c) If neither a) nor b) is available then the Software            Application has to ask the user to manually enter their            MSISDN into the application's user interface. This is then            done and sent to the Server. The Server can then associate            this Software Application's MSISDN with the application's            unique instance ID. If this method is used there might be an            extra step taken by the Server to ensure security or MSISDN            accuracy such as sending back to the entered MSISDN a PIN            number which the user needs to enter into the Software            Application to unlock any purchasing features.

Software Applications built using this Device Adaptive Architectureappear very responsive to the end user. The reason for this is that theMetadata and mark-up language used to define the end user application(see Appendix 4—End User Application Metadata and Mark-up) is storedlocally on the Client in the Software Application as data. This meansthat the application execution platform generated for this Client by theDAA uses this local resource to run the end user application and thusthe speedy appearance.

Software Applications which display lists of content such as news orringtones can utilise this facility to cache their content structuresinside the end user application Metadata definition. This means thatwhen the application is run by the end user it will appear very fastbecause it doesn't need to connect to the Server to access the list ofcontent.

The Client Software Application is able to request an update to anyelement of the Metadata representing the end user application, meaningthat the application is completely updatable over-the-air. This rangesfrom a simple request to update a list of content in one menu, a requestto update all the content in the end user application or to update theentire definition of the end user application itself, effectivelypotentially changing the entire nature of the Software Application.

The end user application is packaged in data files or decks that definethe menus, sub-menus, look & feel elements, screens layouts and anycontent references in the application. Screens are defined in XML usingXML references to resources and content in those screens. The screendefinitions are stored with the content and presentation resources andconverted to binary for packing with the Software Application. Decks canbe referred to from other decks. If the deck referred to is required butis not on the Client it will be requested from the Server. Each deck isloaded from a data stream that is either a file stored in the SoftwareApplication, a record stored in local memory or a file streamed from theServer.

Each deck or item in a deck has an optional expiry date such that it canbe expired and a fresh version downloaded from the Server instead of thelocal deck being used. This is effective for implementing features likecharts or daily changing news. Whenever a user uses part of an end userapplication that utilises a deck where an expiration date is set andpassed, the update mechanism from the Server runs.

There are different types of deck used to store different data dependingon the frequency of expected update, and the space available in eachlocation on the Handset. Items in a more dynamic deck can override thosein a less dynamic deck. (For example configuration in the system deckstored in the application can be superseded by later changes applied tothe deck streamed from the Server).

The Server also has the ability to override any deck in the application,this can be performed when a Software Application makes a connection tothe Server. This effects Server push end user application refreshing orupdating. The Server will provide an update to the element byreferencing the element on the Client and providing the new element.

Where a Software Application connects to the Server via the network todownload a resource and there is a wait whilst that resource isdownloaded, the Client application can display animations and progressbars. The animations are for the purpose of providing some entertainmentfor the eyes and reducing the perceived wait. The progress bar providessome indication of the progress. Where there are no animation librarieson the Client platform these libraries are provided in the SoftwareApplication. They are built using the ability of the Client platform todeploy using X/Y coordinates full or partial pictures to parts of theClient's screen. When combined with timing between these image plots theaffect is one of animation.

Included as part of the Metadata recorded against Handsets and MobileNetworks is information pertaining to the appropriate network connectionsettings for a particular Mobile Network, the mechanism for deliveringthese network settings over-the-air to a Handset and the likelihood ofwhether that Handset/MNO combination is likely to require settings.

Using this information the platform is able to automatically attempt toprovision communications settings to the Handset when it appears thatthey are not present or offer the end user to opportunity to initiatesending settings to themselves. It can also provide instructions on anyadditional manual configuration that the settings require from the enduser once they have been delivered.

All requests made by the Client Software Application to the Server arerecorded in an audit trail on the Server. All actions on the ClientSoftware Application marked in the end user application Metadatadefinition as requiring tracking are communicated to the Server for thesimilar purposes of recording in the audit trail. This means that verysophisticated customer relationship management can be effected becauseof the rich data collected about customer usage. For example this veryrich usage data can be viewed as a set of system operations keyperformance indicators.

All errors in the Client application are recorded by the Client SoftwareApplication and passed to the Server at the next opportunity when theClient successfully communicates with the Server. This allows for adetailed picture to be built up of how the Client Software Applicationis performing in the general Handset populace, and can be used to lookfor trends in any sensitivities Handsets present. This information canalso be used to identify specific newly released Handset firmwareversions which have introduced a bug which needs handling with anadjustment of the Handset Metadata.

The system includes a full service management suite of graphical toolswhich allows Omnifone's partners to manage their own systems. Thesetools are windows on the various configurable Metadata controlling anend user application. Simply by changing the Metadata elements of theservice, e.g. application flow or content structure, the nature of theapplication can be changed.

All interaction between the Client and the Server are recorded and thesystem therefore knows the entire volume of data traffic passing betweenthe Client and Server. This is relevant when network data usage has acost associated and we can work out what the usage level has been andsubsequently what the costs should be given that we have a total numberof bytes transmitted to and from the Server by any Software Application.

The Server monitors for the use of new Phones against the system thathave not yet been seen by the system. If a new Handset attempts todownload a Software Application but the platform cannot find a match,the system will notify the System Administrator. In addition a countwill be kept of requests from each device like this so that the SystemAdministrator can see which devices are the most important to commissionnext based on number of potential users.

The Server implements a ‘Send to a Friend’ feature that can be easilyadded to a Client Software Application. When used, it displays a Send toa Friend option on the Handset's menu. When selected the user can entera friend's MSISDN, sometimes via their Phone's address book if allowed,and an optional greeting. The utility tells the Server to send theapplication to the specified friend. This is done using a technique likeWAP push or MMS.

The Software Application allows the display of advertising messagesbroadcast to the user base of an existing end user application allowingall or a subset of users to be targeted for receiving advertisingmessages via the Software Application. The advertising message is amessage which is delivered as a Server push and is splashed on theappropriate screens. This is facilitated by the flexibility described asavailable to the Server for changing the end user application byeffecting a Server push.

DAA is not just appropriate to delivering applications to Mobile Phones(or indeed Wireless Computing Devices). It is appropriate to situationswhere an application is required to be built for and delivered to alarge number of Client computing devices (including non-Wireless Clientcomputing devices), where:

-   -   The application required is similar for all devices;    -   There are many differences between many of the devices but they        are fundamentally similar and the differences between the        Clients can be described in Metadata and used by the Device        Adaptive Architecture to build the application;    -   The application to be deployed benefits from being able to        understand the differences between devices and provides the best        possible functionality and features for the each device;    -   The application should be described/represented once or as few        times as possible and the Metadata representing the device        characteristics is used to build the custom applications        required by each device rather than the differences required by        the application for each device being described in each version        of the application arrived at by a traditional porting exercise.

Section 2 Mobile Content Portal Overview

Given that the Device Adaptive Architecture is available and theMetadata is present which allows Software Applications to be built for alarge proportion of the world's Mobile Handsets, then some veryappealing mass consumer Network Applications become possible to build.We describe here one such Network Application which contains many uniqueand inventive steps and becomes commercially viable only when it can bebuilt for and distributed to a large proportion of the world's MobilePhones.

This implementation of the invention is a Network Application for theMobile Phone Network that allows users to browse, preview, buy and enjoyMobile Content through a Client Software Application which provides arich user experience able to utilised the advanced features of eachMobile Phone and run on the most Mobile Phones. The Mobile Content isstored on the Server and is accessed from the Wireless Computing Deviceby using the Network Application. The server itself is a portal of thatMobile Content. We shall refer to this Network Application as the MobileContent Portal Software Application.

The features of the Mobile Content Portal Software Application includethe following:

-   -   It is a fast reacting Software Application which is quick to        navigate and browse through categories of Mobile Content and        editorial information.    -   The downloaded Software Application contains a Metadata package        which defines the look & feel of the application, the menu        structures for the content on offer, the branding, the hierarchy        and flow of the screens shown to users, content hierarchy,        content in menus, animations, etc. The Metadata is a full data        description of the application, it's features and it's        behaviour.    -   This definition of the end user Software Application is        converted to binary and compressed to ensure smallest size.    -   For the fastest access to Mobile Content and the fastest        perceived system the application contains a default set of        Mobile Content and associated content structure cached as part        of the end user Software Application definition inside of the        Software Application. This can be navigated by the Software        Application quickly as it is local to the Client.    -   To provide access to a wider selection of Mobile Content a        network based browse function is provided which allows the        Client to show lists and groups of Mobile Content stored on the        Server by accessing the much larger library available over the        Mobile Network connection to the Server.    -   A search function is also provided where the user can type any        phrase into a form in the Software Application and that is then        submitted to the Server over the network where a search will        then be performed over the Mobile Content stored at the Server        and the matching records returned to the Client application.

Content Related Features

-   -   The Handset Metadata enables the system to make sure that each        Software Application for each different Handset type has the        maximum amount of Mobile Content cached on the device without        going too far and consuming too much of the Handsets resources.    -   The Mobile Content database on the Server is rich in Metadata        such that only the correct and most appropriate Mobile Content        compatible with the Mobile Device is offered to the user for        preview and purchase.    -   The application offers users the option to preview Mobile        Content on their Phone before they buy to enable the user to        assess the quality of the Mobile Content before purchase.    -   Where the programming language used to provide the Mobile        Content Portal on the Client (e.g. Java) cannot preview the same        quality Mobile Content preview as the Phone itself can support        (when the Mobile Content is purchased) then the system will        understand the best quality preview that can be delivered due to        a mapping between the content types which can be previewed on        the Phone and a ranking of which types have the best quality.        Examples of lower quality previews are: a different (though        similar) content type, an image dynamically reduced in        dimensions to fit within the device's physical constraints, an        equivalent content file but with greater compression, or simply        a description of the content.    -   Where the system connects to the network for downloading a        preview and there is a wait while that file is downloaded, the        client application provides animations and progress bars. The        animations are for the purpose of providing some entertainment        for the eyes and reducing the perceived wait. The progress bar        for providing some indication of the amount of total time        elapsed or the amount of progress.    -   Where animations are not natively provided by the client        programming language platform then the Software Application        enables this facility by using a number of images which can        overlap partially or fully replace each other controlled by an        x/y placement system and an associated set of timing        information.    -   The application provides clear pricing of each element of the        Mobile Content so the user is clear exactly what the price might        be before purchasing.    -   A “locker” based system where anything that has been previously        purchased is recorded at the Server and subsequently viewable        from within the Client application. The status of each previous        purchase can be seen, where and how much it cost and the status        of the billing. Also a facility to request download of the        Mobile Content again if the Phone has been changed or the Mobile        Content item has been lost. This also includes the ability to        get back a different format of the same Mobile Content item if        the user has upgraded to a different Phone manufacturer which        supports a different format of Mobile Content. This is        facilitated by the extensive Mobile Content and Handset Metadata        on the server where there is an understanding of all the content        types available for each Mobile Content product and an        understanding of which Handsets support which Mobile Content        types.    -   The system monitors the previews and purchases of content by the        user base by recording such events in the Server's audit trail.        The system can then implement a ‘Darwinian survival of the        fittest’ content regime where the Mobile Content items that have        a high sales preview to purchase conversion rate move up the        menus whereas items which are previewed a lot but are rarely        bought move down the menu. This algorithm can also include a        weighting for the depth in the menu that a Mobile Content item        appeared.    -   Information is collected on the handset to understand the best        possible Mobile Content that a handset can display and render.        Given that the content system has detailed knowledge of the        content types available for the user, this allows the system        only to show content to a user that is known to work on that        handset and also is the best type of content which will work on        that handset.    -   Automated engines responsible for taking libraries of content        from a content provider which electronically inspect the        incoming content. The inspection is done through mechanisms such        as introspection where the files which represent each element of        content are electronically opened and inspected. These media        file types generally have information embedded in them which        describe the format and nature of these files. This information        is used to confirm the quality and consistency of the incoming        content data. It is also used to automatically map the incoming        content to the Mobile Devices with which it is compatible.    -   Content menus and the content within them are given a priority        such that Handsets with the smallest capacity get the best menus        and the best content in those menus, even if they have fewer        menus and content items without any menu cached on the Phone.    -   If a menu does not have any items appropriate for a particular        Phone then that menu will not be shown.

White Labeling and Ability to Update

-   -   Such a Mobile Content Portal where all the elements which form        part of the brand of the end user application (e.g. application        name, application icon, splash/startup screen, contents of help        and about pages, branding on application acquisition screens,        references to itself as a named application, etc) are abstracted        to Metadata from the actual application such that they are        independently changeable and thus the system becomes easy to        immediately produced a branded version of the application for        partners. This is otherwise known as white-labeling.    -   The application can provide regularly changing charts, such as        top selling lists and pop charts. These content menus are        present on the Client and have an expiration date. Should a user        enter such a menu and the menu is found to have expired, the        application will connect to the network and request an update of        the latest menu from the Server.    -   When the application is connected to the network for the        purposes of downloading a preview or getting a menu (chart)        update then any element of the end user application can also be        updated by the Server. The Server will provide an update to the        element by referencing the element on the Client and providing        the new element. It can also provide a new element for download        to the Client for incorporation into the end-user application.        This way any element such as branding, content, structure,        screen layout, etc can be changed over-the-air after the        application is installed.

Products in the Portal

In addition to a full range of Mobile Content appropriate for a givenHandset, the Mobile Content Portal also supports the sale of thefollowing products and services.

-   -   The system lets the user order full versions of music downloads        for MP3.    -   The system lets the user browse and order CDs and other physical        media entertainment products.    -   The application allows users to see SMS & MMS alerts services        and to subscribe to one-off and regularly alerts services.    -   The system lets the user view news, stories and events listings        relating to the Mobile Content which can be updated regularly.    -   The system lets the user enter competitions relating to the        content by the filling in of simple forms implanted in screens        by the Software Application, the data entered being passed over        the network to the Server for consolidated reporting.    -   The system can push news and competitions to the customer base,        helping to build a community of interacting users around the        Mobile Content Portal.

Billing Features

A convenient method of billing a user is to have the server send theuser one or more premium SMS messages which terminate at the mobiledevice (mobile terminated, or MT) which amount to the total of the billrequired to purchase an item of content purchased through the MobileContent Portal. Whilst this is convenient, in order to effect it, theMSISDN of the Mobile Telephone is required but some methods ofdelivering a Software Application to the Phone do not allow the MSISDNto be accessed by the Client application—e.g. Java. In this situationour Mobile Content Portal does the following:

-   -   1. At the point of delivering the application to the end user,        record the MSISDN of the user's device in the server's database.        The MSISDN is either detected from the method of request for the        application (e.g. SMS, IVR, etc) or it is requested from the        user in the interface which is collecting the information to        allow application delivery to be performed (e.g. web).    -   2. Dynamically build into the application a unique reference        number (or the MSISDN itself but an indirect reference to the        MSISDN is safer for the user) which is related at the server to        the actual MSISDN.    -   3. The user downloads the application to their Mobile Telephone        which includes this unique reference.    -   4. The Server takes steps (such as deletion) to ensure that this        same application cannot be downloaded again.    -   5. When the application requests the purchase of an item by the        user, the application forwards the reference.    -   6. The Server receives the reference and uses it to determine        the MSISDN.    -   7. Now in possession of the MSISDN the server can perform the MT        SMS billing.

Other billing features include:

-   -   a Intelligent billing: the Server knows if a particular billing        gateway needs to be used in conjunction with the specific Mobile        Content item sold.    -   Mobile Content can flexibly be delivered asynchronously to the        billing, before the billing or after the billing. Billing        delivery receipts received back from the Mobile Network        (generally by asynchronous SMPP) are used for this purpose.    -   Credit limits can be configured such that if the content is        delivered before the billing is performed then a maximum credit        on the system can be achieved.    -   Ability to effect the billing using the client application's        capability to send a SMS (short message service) from the        application to a premium billed number.    -   Ability to effect the billing using the client application's        capability to send a SMS from the Client application to the        Server via the Mobile Network, where the message is received by        the Server and the Server then initiates billing on behalf of        that user either by a method of premium SMS (mobile        terminated/MT), direct Mobile Network operator billing (via        messaging into the MNO's core network), bills to credit or debit        card or some other method of billing possible by a networked        Server computer.    -   Ability to effect billing by having the Mobile Telephone make a        telephone call (automatically or user initiated) to a premium        IVR (interactive voice response) system of the appropriate cost        denomination or such a line where the total costs can be        implemented by having the user hold on the line for a period of        time.    -   Ability to effect billing by sending an SMS to the user which        acts as a voucher for the purchase they have made with an        explanation to forward this voucher to a number. The number to        which they forward this SMS voucher is a premium SMS number        which performs the billing. The contents of the SMS voucher are        then forwarded to the Server which pulls out the voucher number        and then combines it with the MSISDN of the incoming SMS and        confirms which user has fulfilled the payment for which piece of        ordered Mobile Content.    -   Ability to effect billing by sending an SMS to the user where        the sending number of the SMS is set to the same number as is        presented in the SMS, which is a premium rate number, which when        called will implement the billing required for a purchased        product. The billing will be either a particular number which        when called achieves a specific denomination of bill or a line        where the amount deducted from the user increases over time and        the call is terminated by the IVR system when the amount to be        billed has been achieved.    -   Ability to bill customers where a credit system is provided.        Users either call an IVR number and build up credit or send in        SMS to a premium SMS number where the result is a build up        credit for that user which can then be used against purchases of        Mobile Content from the portal.    -   A total purchasing limit enforced over a period of time. This is        implemented by recording all purchases made by a user and only        allowing a purchase to occur if the user has not reached and        will not reach the purchasing limit in the specified period of        time. For example children having a £20 per month spending        limit.    -   A spending limit per individual item of Mobile Content. For        example in the UK children under 16 are not allowed to purchase        items using premium rate services where the cost of the item is        over £3. This can be effected by the Mobile Content selected for        a children's service being controlled by a content management        application aware of this limit.    -   The system is configurable so that particular payment methods        can be used in a country or be flexible enough to change the        nature of part of the application due to local legislation.    -   For a user who doesn't have a compatible Phone, the facility to        use the system on a friend's compatible Phone where they can use        the friend's Phone to locate the Mobile Content they want and        when selected the Mobile Content will be delivered to and        charged to (by way of mobile billing mechanisms such as premium        messaging) to that first user's Phone, and not the friend's        Phone.    -   The service allows one user to buy a gift through the system and        have it delivered to a contact for the purposes of gifting.

Extended Features

-   -   The system implements a customer loyalty mechanism and points        system. Points can be collected for actions such as purchasing        and sending the application to a friend. Points can be redeemed        for Mobile Content or sent to a friend.    -   Send to a Friend—the ability to send the entire application to a        friend. The Software Application collects the friend's MSISDN in        a form and then submits this to a Service on the Server which        sends a WAP push (or similar) invitation to the friend.    -   A feature such as recommend a tone to a friend. This sends a        sample of the content (could be a tone or other item of Mobile        Content) to the specified friend by way of a form on the        Software Application collecting the friend's details and then        sending the preview via the Server. If the friend is a user of        the Mobile Content Portal then the preview is highlighted to        them the next time they use it. If they are not already a user        then the Server will send them a link to download the Mobile        Content Portal. When they access it they will immediate see the        recommended Mobile Content Item.    -   The application can promote new MNO upgrade network and handset        deals using customised pages to promote MNO packages and        phone/network offers.    -   Application can support embedded links to partners WAP and xHTML        sites selling other content.    -   The system stores phone specific data which provides guidance on        how to find the Mobile Content purchased and downloaded on all        types of Phones.    -   System supports international character sets & currencies by        abstracting all text and currencies out to data-driven country        sensitive messages pricing Metadata elements.    -   The content and services offered through the portal can be        location specific. For example at the right time of day for the        football match in the cells near a football ground where team A        is scheduled to play team B, then team A & B focused content can        be prevalent on the portal. This is achieved by combining the        Content Portal's ability to dynamically update the content and        location based services acquired by the Server from the MNO or        MNO aggregator.    -   The application integrates with existing content platforms        easily.    -   The application tracks purchasing of content for the purposes of        paying royalties & licensing rights. These rights are stored        against the Mobile Content records as the amounts (absolute,        percentage or calculated) to be paid to the identified party on        purchase of the Mobile Content item. Combining this data with        the purchase audit trail provides the required royalty payment        details.    -   The application has integrated Digital Rights Management DRM) to        support the fight against content and copyright theft. The        system can be configured only to show certain types of content        to phones supporting a comfortable level of DRM. DRM is a        standard by which content can be easily package when delivered        to the Phone to prevent forwarding from the purchasing device to        another device or to support, for example temporary use for        promotional purposes, by a device.    -   The system has an on-board game called ‘Name that Tone’. The        game presents a number of ringtones whilst one ringtone is        played. The user has to guess which ringtone is playing. It        allows the user the challenge a friend.

APPENDIX 1 Handset Metadata

This section contains details of the type of Metadata collected for eachHandset during the Handset commissioning phase. The Metadata is groupedlogically and described. Various examples are provided of how the valuesof the Metadata can vary from device to device.

The Metadata collected to enable the commissioning of a Handset and thesubsequent delivery of a rich application to Handsets is subject toconstant change. This is due to new features and functions beingreleased in Handsets and the consequential need to continually evolvethe Metadata collected from the Handsets.

Device Identification

manufacturer Which company designs and manufacturers the device. E.g.Nokia, Sony Ericsson, etc name Name of the device e.g. 6600, K700idisplay_name How customers know the phone e.g. Nokia 6600, Sony EricssonK700i. user_agent_expression User Agent Profile (UA Prof) presentedduring a WPA or xHTML session during application download used torecognise a phone. user_agent_evaluation_priority Handling conflictsbetween UA Profiles. group_membership Used to group handsets which havea similar platform together. 3^(rd) party handset identifiers How othersmight refer to handsets e.g. content suppliers or MNOs. phone image Apicture of the phone.

Market Information

popularity rating A sliding scale of popularity used to determine whichhandsets to commission. launch date The date that the handset becameavailable in the market. announcement date The date that the handset wasannounced to the world.

Network Configuration

notification_method Available methods for delivering URLs to the phonee.g. plain text, WAP push network_settings_type Protocol for sendingsettings to phone e.g. OMA, OTA can_send_browser_settings Supportsreceiving browser settings (Y/N) can_send_java_settings Supportsreceiving Java midlet settings (Y/N)device.properties.network.settings.named. Ability to control name ofjava.session settings sent to phonedevice.properties.settings.additional. Additional manual config.requiredconfiguration required from user to set up network settings (Y/N)device.properties.settings.can.configure. Network settings can bemanually manually configured by the userdevice.properties.wap.browser.content- Protocol used by WAP type browser(xHTML/WML)

Physical Characteristics

Screen size (characters) Number of characters displayable on screen.Midlet screen size (pixels) Java addressable screen size. Full screensize (pixels) X & Y pixels for screen size Dynamic memory available(Y/N) Application size limitations Limitatiosn to the size of theapplication. device.properties.recordstore.max-record- Persistent memorysize (Recordstore) record size device.properties.recordstore.max-sizePersistent memory (Recordstore) maximum available

Network Configuration

explicit_java_settings Separate Java settings required (Y/N)defaults_to_wap Java will use browser's settingsconfiguration_complexity User interaction complexity rating

Media/Content Capabilities

Media content types supported by Java e.g. audio types, pictures typesand size, etc. Media content types supported by phone e.g. audio types,pictures types and size, etc. Media content type limitations for Java(image size, max number of channels, max file size, specific form ofcontent type, such as MMF version, image file type, etc) Media contenttype limitations for phone (image size, max number of channels, max filesize, specific form of content type, such as MMF version, image filetype, etc)

HTTP Connection

browser_protocol WAP browser protocol for HTTP communicationsjava_protocol Java midlet protocol for HTTP communicationsdevice.build.properties.connection.concurrent Handles concurrentconnections device.build.properties.connection.primer Connection needspriming device.build.properties.connection.primer. Type of connectionreverse.first.connection priming requireddevice.properties.http.primer.delay.after Delay to user after firstpriming connection device.properties.http.primer.delay.before Delay touse before first priming connectiondevice.properties.connection.apn-choice Prompts user to select from alist of APNs on connection device.properties.connection.max-threadsMaximum threads supporting concurrent connectionsdevice.properties.connection.one-wap- profiledevice.properties.connection.platform- Browser launched fromrequest.http.fails.after midlet will fail to connect if attempted afterJava connection device.properties.connection.platform- Browser launchedfrom request.http.fails.before midlet will fail to connectdevice.properties.connection.platform- Gateway used to openrequest.http.gateway browser from Java. Will either be the browser'sgateway or the Java gateway device.properties.connection.refuse.sessionWhether midlet can reconnect after user has refused the connection.device.properties.connection.timeout Force timeout on connection (don'trely on phone to do it reliably) device.build.http.headers.no-cookiesWhether phone supports cookies

SMS Communications

device.build.properties.sms.port.required Phone requires specificconfiguration for outbound SMS communication device.build.sms.truncatedHandle handset specific bug that some phones have with sending truncatedSMS.

Java APIs & Libraries

device.packages.btapi.1.0 BTAPI version device.packages.cldc.1.0 CLDCversion device.packages.cldc.1.1 CLDC versiondevice.packages.com.samsung.util.audioclip Samsung audio libraryavailable device.packages.com.vodafone.v10 Vodafone audio libraryavailable device.packages.midp.1.0 MIDP 1.0 device.packages.midp.2.0MIDP 2.0 device.packages.mmapi.1.0 MMAPI version device.packages.wma.1.0WMA version device.build.properties.audio.incapable No audio libraryavailable device.properties.jad.attribute.midxlet.api Vendor specificcontrol of JAD contents device.properties.jad.attribute.midxlet.networkVendor specific control of JAD contentsdevice.properties.jad.attribute.rms.size Vendor specific control of JADcontents

Java Application Security

device.properties.jad.attribute.signed.required Application signingdevice.properties.jad.attribute.signing.keystore. Application signingname authority and mechanism required

User Interface Capabilities

device.build.screen.canvas.limitation Manage memory limitation on somephones device.build.screen.canvas.refresh Handle problems with refreshparts of the screen on some phones device.build.screen.command.selectdevice.build.screen.items.pool Handle memory management problems somephones have with creating and clearing up display objects.device.properties.progress.connect.range Gauge behaviourdevice.properties.progress.download.range Gauge behaviour

Miscellaneous Capabilities

device.build.system.explicit.garbage.collection Give hints to JVM tohelp it with memory management. Used on lower memory phones.device.build.history.reference Manage memory limitation on some phonesdevice.build.image.unreliable.creation Phone-specific runtime bugworkaround device.properties.jad.static Handle JAD naming restrictionson some phones device.properties.preview.png.dimensions Handle handsetspecific bug with displaying some images

User Assistance Properties

Properties used for providing user assistance throughout the platform.

help.install.bookmark.create.how How to bookmark a WAP pagehelp.install.java.how How to install a Java midlethelp.install.java.location.how How to find a Java midlethelp.install.java.location.where Where to find a Java midlethelp.install.java.outmemory.how How to deal with out of memory errorshelp.install.java.upgrade.how How to upgrade a Java midlethelp.install.sms.location.how How to find a plain text SMShelp.install.sms.location.where Where to find a plain text SMShelp.install.sms.use.how How to use a URL in a plain text SMShelp.install.smsbookmark.create.how How to create a bookmark from a SMSURL help.install.wsi.location.how How to find a WAP Pushhelp.install.wsi.location.where Where to find a WAP Pushhelp.install.wsi.use.how How to use a WAP Pushhelp.settings.gprs.enable.how How to enable GPRShelp.settings.java.activate.how How to active sent Java network settingshelp.settings.java.save.how How to save sent network settingshelp.settings.wap.activate.how How to activate sent WAP network settingshelp.settings.wap.overwrite.how How to overwrite existing WAP settingshelp.settings.wap.save.how How to save sent WAP network settingshelp.usage.bookmark.find.how How to find a bookmarkhelp.usage.content.game.how How to use a gamehelp.usage.content.game.location.how How to find a gamehelp.usage.content.game.location.where Where to find a gamehelp.usage.content.realtone.how How to use a realtonehelp.usage.content.realtone.location.how How to find a realtonehelp.usage.content.realtone.location.where Where to find a realtonehelp.usage.content.ringtone.how How to use a ringtonehelp.usage.content.ringtone.location.how How to find a ringtonehelp.usage.content.ringtone.location.where Where to find a ringtonehelp.usage.content.texttone.how How to use a texttonehelp.usage.content.texttone.location.how How to find a texttonehelp.usage.content.wallpaper.how Where to find a texttonehelp.usage.content.wallpaper.location.how How to use a wallpaperhelp.usage.content.wallpaper.location.where How to find a wallpaperhelp.usage.java.browser.how Where to find a wallpaperhelp.usage.java.easy.location.how How to make it easy to find a midlethelp.usage.wap.easy.location.how How to make it easy to find a WAPbookmark

APPENDIX 2 Handset Software Component Library

This appendix lists the type and nature of Software Components in thelibrary which are utilised by the Device Adaptive Architecture to selectfrom in the build of an application for a handset. These components areconstantly changing due to the constant evolution of Handsets and thesubsequent requirement for new and modified Software Components.

Core Components

Core handset components are listed below:

-   -   Audio Player Component    -   Animation Component    -   String Display Component    -   Image Display Component    -   List Display Component    -   Gauge Component    -   TextField Component    -   HTTP Communication Component    -   Browser opening Component    -   SMS Sending Component    -   Command (soft key) options Component    -   GZIP Component    -   Memory Persistence (RMS) Component    -   Video Player Component    -   File Persistence Component    -   Checkbox Component    -   Radio button Component    -   SMS Receiving Component    -   Bluetooth Communications Component

Component Variants

Each component has several variants. Typical examples are shown below:

-   -   Audio Player Component Variants—Always one of the following        -   No Audio Player        -   “Standard” MMAPI Audio Player        -   Samsung Audio Player        -   VSCL (Vodafone) Audio Player        -   Siemens Audio Player    -   HTTP Communications Variants—Any combination of the following:        -   “Standard”        -   User Identifier in Cookie/User Identifier in URL        -   Expected unreliable connection        -   Handle concurrent connections    -   SMS Sender Variants:        -   With port number/Without port number on request        -   “Standard” WMA        -   Siemens SMS Variant        -   Samsung SMS Variant        -   With message padding/Without message padding (handling            device specific bugs)    -   Browser open Variants:        -   Can't open WAP from Java        -   Can only open wap from java if we haven't tested the java            http connection        -   Can open wap from java but requires java http settings        -   Can open wap from java using the wap settings

Sub-Components

Each component/component variant has several Sub-Components which can becontrolled by different properties. Examples are shown below:

-   -   Audio Player Component        -   Create Audio Player with suitable content/content-type            component        -   Start Audio Player component        -   Stop Audio Player component        -   Detect End of Playing Audio component        -   Destroy Audio Player component    -   HTTP Communications Component        -   Create URL component        -   Create HTTP headers component        -   Create connection component        -   Make HTTP request component        -   Detect HTTP status component        -   Retry HTTP component    -   SMS Sender Component        -   Create SMS object component        -   Create SMS connection component        -   Send SMS component    -   Memory Persistence (RMS)        -   Create record        -   Read record        -   Update record        -   Delete record        -   Split record        -   Join record    -   Animation Component        -   Display animation        -   Size animation        -   Prioritise animation        -   Animation rate    -   Command (soft key) Sub-Components        -   Open screen in JAR        -   Open screen stored in RMS        -   Open screen in current deck        -   Download deck over HTTP and open screen        -   Send SMS        -   Open URL in WAP browser

APPENDIX 3 Examples of Mapping of Handset Metadata to SoftwareComponents

Any of the Software Components in the library can be associated with anynumber of device properties. The association with a property may bebased on any of the following tests:

-   -   A direct property existence test (e.g. property A must exist for        this Software Component to be compatible or used).    -   A comparative property value test (e.g. property B must have a        value greater than X for this Software Component to be used)    -   A comparative test of a device property value against a Software        Component property value. (e.g. device property C must have a        value less than Software Component property SC for this Software        Component to be used)    -   Ratings mechanisms which allow the most suitable of a set of        compatible Software Component to be selected (e.g. where more        than one Software Component is compatible, select which is the        best fit for purpose by selecting that Software Component where        the component attribute SC has the greatest value)    -   Any combination of the above

Some examples of how these properties are mapped to library SoftwareComponent are given in this section.

Build Audio Player Component

-   -   Select audio package to include and use based on setting of the        device's properties whose names match the wildcard        “device.package.*”    -   If more than one audio package is supported by the device, then        the package which offers support for the widest selection of        audio types will be automatically selected. This decision is        made by comparing the list of supported packages described by        “device.packages.*” against the capabilities of each of the        supported Audio Player Component Variants.    -   Exclude audio player component if phone does not support audio        indicated by the device.build.properties.audio.incapable        property    -   Include “No preview available” components if no audio available

HTTP Communication Component (Create Connection Sub-Component)

-   -   Include additional connection (primer) request according to        setting of device.build.properties.connection.primer property

SMS Sender Component

-   -   Construct SMS request according to        device.build.properties.sms.port.required and        device.build.sms.truncated properties

Animation Component

-   -   Use a form instead of canvas when resources are limited based on        device properties: handset grouping, available dynamic memory.

Browser Opening Component

-   -   Include platform request sub-component only if functionality is        supported on handset, indicated by existence of        device.packages.midp.2.0 for device.    -   But exclude component if either        device.properties.connection.platform-request.http.fails.after        or        device.properties.connection.platform-request.http.fails.before        is set.

Tuning

Some Software Components, once included, are further tuned according tothe value of device Metadata properties. For example:

HTTP Communication Component (Create Connection Sub-Component)

-   -   Control sequence of primer connection attempt and main        connection based on the values of        device.properties.http.primer.delay.before and        device.properties.http.primer.delay.after properties.    -   Control time delay between primer connection attempt and main        connection attempt based on the values of        device.properties.http.primer.delay.before and        device.properties.http.primer.delay.after properties.    -   Switch the order of these according to        device.build.properties.connection.primer.reverse.first.connection

Animation Component

-   -   Select correct sized animation according to which of a set of        ranges the device's screen dimensions and available memory lie        within.    -   Tune animation frame rate according to available resources        described in properties: group membership, screen dimensions,        available dynamic memory    -   Tune animation thread priority according to available resources        to balance animation smoothness against other processing        happening on the handset. Controlled by examining properties:        group membership, available dynamic memory.

Memory Persistence (RMS) Component

-   -   This component is tuned for the particular device by controlling        the maximum size of individual records and also the number of        records. This is controlled by handset properties        device.properties.recordstore.max-record-size and        device.properties.recordstore.max-size    -   This allows data to be persisted via this Software Component        without the application needing to know how the data is        fragmented in the underlying storage. Data can be split over        several records.

APPENDIX 4 End User Application Metadata and Mark-Up

Provided below are examples of screen definitions for end-userapplications built on top of the Device Adaptive Architecture. Theseexamples show the three core types of screen—the form, the canvas andthe list. These eXtended Mark-up Language XML) descriptions describe theapplication screen in full, and show how the definition is used tocontrol the presentation aspects of the screen, and control command-flowthrough the application. This is effectively the mechanism by which theClient part of a Wireless Client Network Application can be defined andbuilt without writing software code.

Some of the specific features shown in these examples are:

-   -   Display and user interaction objects can be included    -   More sophisticated objects like Player and Images can be        included and controlled    -   Variables can be set and read.    -   Test conditions can be checked against variables    -   Full access is given to all attributes of the standard MIDP        objects    -   Command buttons refer to other screens. Those screens will be        already present on the client, or may have to be automatically        loaded from the server.

Form Example

<form id=“SearchFailure” title=“Problem”>  <command label=“OK” type=“ok”priority=“0” go=“Index.do” />  <command label=“Back” go=“${previous}”type=“back” priority=“1” />  <string-item text=“An error has occurredand the search can't be performed - the network might be busy. Pleasetry again later.” />  </form> <canvas id=“LoadingFriend” title=“”interval=“400”>  <commend label=“Cancel” go=“${previous}” type=“stop”priority=“0” />  <image-item key=“midp.system.loading.image”src-deck=“system” x=“7” y=“7” />  <gauge x=“64” y=“98” size=“small” /> <string-item if=“connect” since=“1.3.1” text=“Connecting.” x=“64” y=“7”width=“64” size=“small” />  <string-item unless=“connect” text=“SendingMyFone...” x=“64” y=“7” width=“64” size=“small” />  </canvas>

Canvas Example

<canvas id=“Preview” title=“Free Preview” interval=“400” loopcount=“1”> <player src=“/previews/17651” loopcount=“1” contentType=“audio/midi” /> <image-item key=“midp.system.loading.image” src-deck=“system” x=“7”y=“7” />  <string-item text=“Free preview! Select the Buy option to buythis ringtone for GBP3.00.” x=“64” y=“7” width=“64” size=“small” /> <string-item text=“Friends by TV Theme” x=“7” y=“98” width=“114”size=“small” />  <command label=“Back” go=“${previous}” type=“back”priority=“1” />  <command label=“Buy” go=“#Buy” type=“ok” back=“false”priority=“0” />  <command label=“Play” go=“#Preview” type=“screen”back=“false” priority=“1” /> − <command label=“Terms”go=“Index.do#Terms” type=“screen” priority=“9” back=“false”>  <setvar=“last.card” val=“Preview.do?id=2038#Preview” />  </command> </canvas>

List Example

<list id=“Cat61” title=“Music Celebs”>  <include id=“#ProductList” /> <set var=“category.id” value=“61” />  <set var=“category.name”value=“Music Celebs” />  <set var=“topCategory.id” value=“2” />  <setvar=“topCategory.name” value=“Wallpapers” />  <append id=“5496”text=“Atomic Kitten 2” image=“myfone/shared/icons/wallpaper.png”src-deck=“system” />  <append id=“5500” text=“Sugababes 1”image=“myfone/shared/icons/wallpaper.png” src- deck=“system” />  <appendid=“5506” text=“Ronan Keating 5”image=“myfone/shared/icons/wallpaper.png” src-deck=“system” />  <appendid=“5520” text=“Busted 1” image=“myfone/shared/icons/wallpaper.png” src-deck=“system” /> </list>

XML DTD

The following is a XML DTD (Document Type Definition) which describesthe mark-up syntax available to use when building end-user applications.

<!--- Collection of related screens. --> <!ELEMENT collection(list|form|canvas|template|initialize)*> <!ATTLIST collection   id CDATA#REQUIRED   default CDATA #IMPLIED   onConnectRefused CDATA #IMPLIED  onConnectError CDATA #IMPLIED   onLoad CDATA #IMPLIED   onError CDATA#IMPLIED  > <!--- Variables to set on initialization. --> <!ELEMENTinitialize (set)*> <!--- A variable to set. --> <!ELEMENT set EMPTY><!ATTLIST set   var CDATA #REQUIRED   val CDATA #REQUIRED   scope(card|deck|session|rms) session  > <!--- Template to include on otherscreens. --> <!ELEMENT template(timer|string-item|gauge|image-item|command)*> <!ATTLIST template   idCDATA #REQUIRED  > <!--- Command to run on user selection. --> <!ELEMENTcommand (set|go)*> <!ATTLIST command   go CDATA #IMPLIED   label CDATA#IMPLIED   back (back) #IMPLIED   priority NUMBER #IMPLIED   type CDATA#IMPLIED   onConnectRefused CDATA #IMPLIED   onConnectError CDATA#IMPLIED   onLoad CDATA #IMPLIED   onError CDATA #IMPLIED  > <!---Screen to open. --> <!ELEMENT go EMPTY> <!ATTLIST go   location CDATA#REQUIRED   if CDATA #IMPLIED   unless CDATA #IMPLIED   refresh(refresh) #IMPLIED   onConnectRefused CDATA #IMPLIED   onLoad CDATA#IMPLIED   onConnectError CDATA #IMPLIED   onError CDATA #IMPLIED  ><!--- Canvas screen. --> <!ELEMENT canvas(timer|string-item|gauge|image-item|command)*> <#ATTLIST canvas   idCDATA #REQUIRED   loopcount NUMBER #IMPLIED   interval NUMBER #IMPLIED > <!--- Image to display. --> <!ELEMENT image-item EMPTY> <!ATTLISTimage-item   layout (default|left|right|center) default   newline(before|after|none) none   y CDATA #IMPLIED   x CDATA #IMPLIED   heightCDATA #IMPLIED   width CDATA #IMPLIED   src-deck CDATA #IMPLIED   keyCDATA #IMPLIED  > <!--- Player to initialize. --> <!ELEMENT playerEMPTY> <!ATTLIST player   src %URI; #REQUIRED   contentType CDATA#IMPLIED   loopcount NUMBER #IMPLIED  > <!--- Connection gauge todisplay. --> <!ELEMENT gauge EMPTY> <!ATTLIST gauge   size(default|small|large) default   y CDATA #IMPLIED   x CDATA #IMPLIED   ifCDATA #IMPLIED   unless CDATA #IMPLIED  > <!--- String to display. --><!ELEMENT string-item EMPTY> <!ATTLIST string-item   text CDATA#REQUIRED   if CDATA #IMPLIED   unless CDATA #IMPLIED   frames NUMBER#IMPLIED   frame NUMBER #IMPLIED   align (default|left|right|center)#IMPLIED   size (default|small|large) default   width CDATA #IMPLIED   yCDATA #IMPLIED   x CDATA #IMPLIED   since CDATA #IMPLIED  > <!--- Formscreen. --> <!ELEMENT form(image-item|text-field|command|string-item|include)*> <!ATTLIST form  title CDATA #REQUIRED  > <!--- Textfield for user to enter data. --><!ELEMENT text-field EMPTY> <!ATTLIST text-field   id CDATA #REQUIRED  maxsize NUMBER #IMPLIED   constraints(any|emailaddr|numeric|phonenumber|url|password) any   label CDATA#IMPLIED  > <!--- List screen. --> <!ELEMENT list(set|include|append|itemCommand|command)*> <!ATTLIST list   title CDATA#REQUIRED   id CDATA #REQUIRED  > <!--- Item on a list that runs acommand when selected. --> <!ELEMENT itemCommand EMPTY> <!ATTLISTitemCommand   go CDATA #REQUIRED   image CDATA #IMPLIED   text CDATA#REQUIRED   back (back) #IMPLIED   onLoad CDATA #IMPLIED   expires CDATA#IMPLIED   src-deck CDATA #IMPLIED  > <!--- Item on a list. --><!ELEMENT append EMPTY> <!ATTLIST append   id CDATA #REQUIRED   textCDATA #REQUIRED   src-deck CDATA #IMPLIED   image CDATA #IMPLIED  ><!--- Include a template on this screen. --> <!ELEMENT include EMPTY><!ATTLIST include   id CDATA #IMPLIED  > <!--- Run command after timeinterval. --> <!ELEMENT timer (go)*> <!ATTLIST timer   delay NUMBER#IMPLIED   go CDATA #IMPLIED  >

APPENDIX 5 Network Operator Metadata

The key Metadata used within the system for adjusting behaviour andbuilds according to the capabilities of a particular user's MNO arelisted below.

name Identification display_name Identification operator_codeIdentification country Identification Company Identificationwalled_garden GPRS openness reliable_delivery_receipts SMS systemreliability on operator parent_operator_id For managing virtualoperators (MVNOs) supports_contract Contract types offered supports_paygContract types offered supports_gprs_on_contract Offers dataconnectivity supports_gprs_on_payg Offers data connectivitycontact_number_payg_from_mobile Operator customer contact detailscontact_number_contract_from_mobile Operator customer contact detailscontact_number_payg_from_other Operator customer contact detailscontact_number_contract_from_other Operator customer contact detailstypical_apn_names Network typical names

System behaviour must be adjusted to the capabilities of the MobileNetwork gateway that the Handset application is communicating with. TheDAA understands each MNO gateway through Metadata as set out below:

name Identification proxy_ip Gateway connection parameters proxy_portProxy port access_point Access point naming login_type Type of loginrequired username APN username password APN password homepage Homepagedefinition protocol Gateway communication protocol contract_typeContract types this gateway is used with

1. A method of providing content to a Wireless Computing Device,comprising the steps of: (a) automatically generating a customisedNetwork Application suitable for that type of Wireless Computing Device;(b) deploying that Network Application on that Wireless ComputingDevice; (c) the Network Application downloading a preview of content ondemand by an end-user from a Server, the Server storing the content; (d)the Network Application playing the preview of the content; (e) theNetwork Application displaying an option or function that enables theend-user to download and buy that content from the Server.
 2. The methodof claim 1 in which the mobile content is selected from the followinglist: ringtones, wallpapers/pictures, screensavers, realtones/truetones,full music downloads, video, SMS & MMS alerts, and mobile games.
 3. Themethod of claim 1 in which attributes for that type of WirelessComputing Device are defined as meta-data; attributes for variousdifferent kinds of mobile content are also defined as meta-data; and theServer determines what content is compatible with the Wireless ComputingDevice by comparing the meta-data of the content and the WirelessComputing Device.
 4. The method of claim 3 in which the Server downloadsto the Wireless Computing Device only content, or previews of content,that is compatible with the Wireless Computing Device.
 5. The method ofclaim 1 in which the step of automatically generating the customisedNetwork Application involves the following steps: (a) automaticallydetermining attributes of that type of Wireless Computing Device; (b)automatically determining which Software Components from a library ofSoftware Components are compatible with that type of Wireless ComputingDevice based on values of the attributes determined in (a); (c)automatically combining the compatible Software Components together togenerate a customised build of the Network Application, compatible forthat type of Wireless Computing Device.
 6. The method of claim 5 inwhich the attributes of the Software Components are also determined andthe step of determining which Software Components are compatibleincludes the step of comparing the values of the attributes of that typeof Wireless Computing Device to the values of the attributes of theSoftware Components.
 7. The method of claim 5 in which attributes forthat type of Wireless Computing Device are defined as Metadata.
 8. Themethod of claim 5 in which the attributes for different types ofWireless Computing Device are also defined as Metadata.
 9. The method ofclaim 8 in which the method includes the further step of determiningattributes of a Wireless Network, to which the Wireless Computing Deviceis connected, as Metadata.
 10. The method of claim 9 in which the methodincludes the further step of determining attributes of combinations ofdifferent Wireless Networks and different types of Wireless ComputingDevices as Metadata.
 11. The method of claim 7 in which the Metadataattributes for different types of Wireless Computing Device define oneor more of: Wireless Computing Device identification; marketinformation; network configuration; physical characteristics; networkconfiguration; media/content capabilities; HTTP connection; SMScommunications; Java APIs and libraries; Java application security; userinterface capabilities; user assistance properties.
 12. The method ofclaim 9 in which the Metadata attributes for the Wireless Networkinclude one or more of the following: identification; openness; SMSsystem reliability; parent operator ID; contract types offered; dataconnectivity offered; customer contact details; typical network names.13. The method of claim 5 in which the Software Components in thelibrary are restricted in functionality so that appropriate componentscan be matched to any variant of any attribute of that type of WirelessComputing Device or Wireless Network to which that type of WirelessComputing Device can be connected or combination of the two.
 14. Themethod of claim 1 in which the downloaded Network Application includesdata defining the user interface and user interaction processes for thatNetwork application, the data being updatable over the wireless network.15. The method of claim 1 in which the downloaded Network Applicationdownloads from the Server updatable menu lists defining availablecontent.
 16. The method of claim 15 in which the lists include lists ofbest selling items or charts.
 17. The method of claim 16 in which theselists have an expiration date and, should a user enter such a list andthe menu list is found to have expired, the Network Application willconnect to the Server over the network and request an update of thelatest menu list from the Server.
 18. The method of claim 1 in which thedownloaded Network Application displays an option or function thatenables the end user to buy a CD corresponding to the content.
 19. Themethod of claim 1 in which the Network Application is provided with themobile MSISDN telephone number of the Wireless Computing Device by theServer, enabling the application to undertake mobile terminated billing.20. The method of claim 1 in which the Server records the MSISDN of theuser's Wireless Computing Device in the Server's database and undertakesmobile terminated billing using that MSISDN.
 21. The method of claim 20in which the Server builds into the Network Application a uniquereference number which is related at the Server to the actual MSISDN,such that, when the Network Application requests the purchase of an itemof content by the user, the Network Application forwards the uniquereference to the Server, the Server receives the reference and uses itto look up the MSISDN and then uses the MSISDN for mobile terminated SMSbilling.
 22. The method of claim 1 in which automated engines,responsible for taking libraries of content from a content provider,confirm the quality and consistency of the incoming content data andautomatically map the incoming content to the Wireless Computing Deviceswith which it is compatible.
 23. The method of claim 1 in which theServer understands the best quality preview that can be delivered to theWireless Computing Device due to a mapping between the content typeswhich can be previewed on the Wireless Computing Device and a ranking ofwhich types have the best quality.
 24. The method of claim 1 in which,when the Network Application is connected to the network for thepurposes of downloading a preview or getting a menu (chart) update, thenany element of the Network Application can also be updated by theServer.
 25. The method of claim 1 in which, when a Network Applicationconnects to the Server it presents a unique instance ID that wasembedded at time of dynamic build and download to this particularWireless Computing Device and the Server looks-up the version of thisNetwork Application.
 26. A Network Application that is customised for aspecific type of Wireless Computing Device, the Network Applicationbeing downloaded from a Server to that Wireless Computing Device and,when running on the Wireless Computing Device, is operable to: (a)download a preview of content on demand by an end-user from the Server;(b) play the downloaded preview of the content; (c) display an option orfunction that enables the end-user to download and buy that content fromthe Server.
 27. A content portal programmed to be able to download theNetwork Application of claim 26 to a Wireless Computing Device and toprovide content on demand to the Wireless Computing Device.
 28. Mobilecontent when provided to a Wireless Computing Device using the method ofclaim 1.